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(54) Cache managennent techniques 

(57) In general, an apparatus for managing availa- 
ble cache memory in a browser are disclosed. Any doc- 
ument stored in a cache memory not having associated 
with it a strong reference is subject to being reclaimed 
by a garbage collector. The most recently requested 
documents, however, are stored in the cache memory 
with strong references associated therewith thereby 



precluding them from being reclaimed until such time as 
the strong reference is abolished. The strong reference 
is abolished when the document identifier associated 
with the document stored in the cache memory is not 
present in the document stack. Therefor, only the most 
recently requested documents remain stored in the 
cache memory depending upon the depth of the docu- 
ment stack. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of Invention £ 

[0001] . The invention relates generally to memory sys- 
tems. More particularly, methods and apparatus for 
managing the available memory space in a cache mem- 
ory is disclosed. io 

2. Description of Relevant Art 

[0002] The explosive growth in Internet traffic has 
made it critical to look for ways of accommodating the '5 
increasing number of users while preventing excessive 
delays, congestion and widespread blackouts. For the 
past several years a large proportion of Internet traffic 
has been generated by web-browsing and most of the 
web browsing traffic is in turn comprised of images. This 20 
trend will continue with more sites becoming media rich 
as the users' access bandwidths increase and media- 
enabled PCs become more common. This has led to a 
great deal of effort being devoted to studying web cach- 
ing techniques. 25 
[0003] One such web caching technique is referred to 
as proxy based caching. With proxy based caching, cli- 
ents can designate a host to serve as a proxy for all or 
some of their requests (e.g., http, ftp, etc). The proxy 
acts as a cache by temporarily storing on local disks, or 30 
memory, objects that were requested by the clients. It 
should be noted that in the context of the Internet, an 
object is a file, text, image, audio, executable program, 
and the like which is available to be downloaded by a 
client. When one of the clients sharing the proxy gener- 35 
ates a request, the proxy searches its local storage for 
the requested object. If the object is available locally (hit) 
it is sent to the client, othenwise (miss) the request is 
passed on to the remote server or to another proxy serv- 
er, if the proxy cache belongs to a hierarchy of caches. 40 
Unfortunately, if the ratio of number of misses to hits is 
even relatively small, then the performance of the 
browser can be substantially degraded as the requested 
documents must be retrieved from other proxies or the 
remote servers. 

[0004] Another well known web caching technique 
used to improve performance is referred to as client side 
caching. Client side caching is the temporary storage of 
web objects (such as HTf^lL documents) in local cache 
memory for later retrieval. Advantages to client side 
caching include; reduced bandwidth consumption since 
fewer requests and responses that need to go over the 
network are created, reduced server load since fewer 
requests for a server to handle are made, and reduced 
latency since responses for cached requests are avail- -55 
able immediately and closer to the client being sensed. 
In most cases, client side caching can be performed by 
the client application and is built into, for example, Net- 



scape's Communicator, Microsoft's Internet Explorer, 
various Java browsers, as well as most other web 
browsers. 

[0005] Since web browsers (and the computers that 
support them) have only finite disk space, they must 
eventually discard old copies of stored documents to 
make room for new requests. Most systems use a policy 
based on discarding the least recently requested docu- 
ment as being the least likely to be requested again in 
future. Given sufficient disk space, documents are dis- 
carded around the time when they would, in any case, 
have been replaced by a more up-to-date version. How- 
ever, if disk space is insufficient then the cache may be 
forced to discard a current document and make an un- 
necessary connection to the source host when the doc- 
ument is next requested. The amount of disk space re- 
quired depends on the number of users served and the 
number of documents requested. Ideally a cache should 
have room to store every document which the users of 
the cache request more than once during the lifetime of 
the document. Such a cache would never retrieve a sec- 
ond copy of an unchanged document and thereby gen- 
erate the minimum possible network traffic. To achieve 
this in practice would, of course, involve storing every 
requested document locally since there is no way to pre- 
dict which documents will be re-read in the future. 
[0006] Since storing every requested document for at 
least its lifetime is impractical, the number of documents 
which must be reclaimed (or garbage collected) from the 
cache memory is directly related to the available cache 
memory space. As is well known in the art, garbage col- 
lection is a process whereby inactive, or othenwise un- 
neccessary objects, are identified, collected, and deac- 
tivated. If too many documents, or if those documents 
which are frequently requested arc garbage collected, 
system performance is degraded since the document 
must be retrieved from the network if it is not stored in 
the local cache memory. Conversely, if documents that 
are not frequently requested are not periodically gar- 
bage collected, then the limited memory space available 
in the local cache memory can be quickly saturated. 
When this occurs, no new documents can be stored 
and, again, system performance is degraded since re- 
quested documents not stored in the local cache mem- 
ory must again be retrieved from the network. 
[0007] Therefore, what is desired is an efficient meth- 
od and apparatus for intelligently purging documents 
from a local cache memory in a browser environment 
based upon the available cache memory and browser 
traffic. 

SUMMARY OF THE INVENTION 

[0008] Broadly speaking, the invention relates to an 
improved method, apparatus and computer system for 
efficiently managing available memory space in a cache 
memory. The invention can be implemented in numer- 
ous ways, including as a method, a computer system, 
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and an apparatus. Several embodiments of the inven- 
tion are discussed below. 

[0009] According to one aspect of the present inven- 
tion, a computer-implemented cache memory manager 
is disclosed. The cache memory manager includes a 5 
document key stack having a depth of stack locations 
each being arranged to store a document key associat- 
ed with a document stored in the cache memory indicat- 
ing the associated document has a strong reference as- 
sociated with it. The manager also includes a master 
document file having a plurality of file locations each be- 
ing arranged to store a document identifier used to 
uniquely identify an associated document stored In the 
cache memory indicating the associated document has 
only a weak reference associated with it, A garbage col- 
lector is also included that reclaims those documents 
stored in the cache memory that are only weakly refer- 
enced and not those documents that are strongly refer- 
enced. In this way cache memory space commensurate 
with the reclaimed documents is periodically made 
available to store more recently requested documents. 
[0010] In another embodiment, the number of stack 
locations are adjusted to provide sufficient cache mem- 
ory space to accommodate the most recently requested 
files in the cache memory. 

[0011] In another aspect of the invention, a method 
for managing available cache memory space in a cache 
memory is disclosed. If a document key associated with 
a requested document is present in the document key 
stack, then the document key associated with the re- 50 
quested document is moved to a first stack location. 
Those documents stored in the cache memory that do 
not have corresponding document keys present in the 
document key stack are reclaimed by the garbage col- 
lector, such that cache memory space commensurate 35 
with the reclaimed documents is periodically made 
available to store more recently requested documents. 
[001 2] These and other advantages of the present in- 
vention will become apparent upon reading the following 
detailed descriptions and studying the various figures of 
the drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] The invention, together with further advantag- 
es thereof, may best be understood by reference to the 
following description taken In conjunction with the ac- 
companying drawings in which: 

Fig. 1 shows a web browser incorporating a cache 50 
memory manager in accordance with an embodi- 
ment of the invention; 

Fig. 2 illustrates a cache memory manager In ac- 
cordance with an embodiment of the invention; 
Fig. 3 illustrates a situation where the document that 55 
has not been recently requested and as such its 
document key has been dropped from the docu- 
ment key stack: 



Fig. 4 illustrates a new document key stack that has 
been created by the cache memory manager hav- 
ing a reduced number of locations in accordance 
with an embodiment of the invention; 
Fig. 5 illustrates a self regulating cache memory 
manager in accordance with an embodiment of the 
invention; 

Fig. 6 shows a flowchart detailing a process for re- 
trieving a document in accordance with an embod- 
iment of the invention; 

Fig, 7 is a flowchart detailing a process for retrieving 
a document using the associated document key and 
document URL in accordance with an embodiment 
of the invention; 

Fig. 8 is a flowchart detailing a process for setting 
a reference key stack depth in accordance with an 
embodiment of the invention; 
Fig. 9 shows a general computer system useful in 
implementing the Invention. 

DETAILED DESCRIPTION OF THE EMBODIIVIENTS 

[0014] In the following description, frameworks and 
methods of cache memory management in browser en- 
vironment are described. The invention will initially he 
described in terms of a browser application residing in 
a PC environment. In general, when a browser having 
a local cache memory receives a document request in 
the form of a document URL (universal resource loca- 
tor), a determination is made whether or not a document 
key associated with the requested document is present 
in an adjustable document key stack. The document key 
is then moved to a first position in the stack indicating 
the requested document is the most recently requested 
document and is therefore the least likely document to 
be subject to being reclaimed during garbage collection. 
When there is not an associated document key present 
in the document key stack, a master document list is 
updated to include the requested document URL, A new 
document key associated with the requested document 
URL, is then instantiated and inserted into the first po- 
sition in the document key stack. 
[0015] In one embodiment, any document stored in 
the local cache memory not having its corresponding 
document key in the document key stack is subject to 
being reclaimed during garbage collection. In this way, 
the number of reclaimable documents stored in the 
cache memory can be varied based upon the depth of 
(i.e., the number of available positions in) the document 
key stack. The depth of the document key stack can be 
determined by, for example, the amount of available 
cache memory space and/or browser traffic. In this way, 
browser performance can be improved by judiciously 
managing the number and types of documents residing 
in the local cache memory at any particular time. 
[0016] In those situations where local cache memory 
is limited, which is common in embedded devices such 
as Internet telephones, and the like, the depth of the 
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document key stack can be set shallow. By shallow, it is 
meant that the number of documents stored within the 
local cache memory that are not subject to garbage col- 
lection can be reduced such that substantial memory 
space can be periodically made available. On the other 
hand, in those situations where cache memory space is 
not strictly limited, or where system performance is a 
more important consideration then memory space avail- 
ability, such as in PC browser-Internet applications, the 
depth of the document key stack can be increased. In 
this way, the local cache memory stores relatively more 
documents that are not subject to garbage collection 
providing enhanced system performance. System per- 
formance is enhanced since more of the recently re- 
quested documents are stored locally and can thus be 
retrieved without resorting to accessing the network or 
proxy cache memories. 

[0017] Typically, the least recently accessed docu- 
ments will be preferentially reclaimed from the local 
cache memory in order to accommodate those most re- 
cently requested documents. It should be noted, how- 
ever, that any appropriate scheduling protocol can be 
followed as deemed appropriate for the application at 
hand. 

[0018] Most web browsers have a very simple ap- 
proach to networking as illustrated in Fig. 1. Given a 
browser 100 and a URL (univeTsal resource locator) 
containing a host name and a document on that host, a 
parser 1 02 included in the browser 1 00 breaks up (pars- 
es) the URL into a named host portion 104 and a re- 
quested document portion 106. In one embodiment of 
the invention, the requested document 106 takes the 
form of HTML (Hyper Text Markup Language) state- 
ments well known to those skilled in the art. 
[0019] In the case where the requested document is 
not stored in a local cache memory 108, the parser 102 
makes a TCP ("transmission control protocol") connec- 
tion to the named host portion 1 04 and retrieves the con- 
tents that include the document portion 105 of the re- 
quested URL. In one embodiment, the URL contents re- 
trieved from the named host portion 1 04 includes those 
HTML statements corresponding to the requested doc- 
ument portion 106. The parser 102 uses the HTML 
statements corresponding to the requested document 
portion 106 to form what is referred to as an instance of 
the document object model (DOM) 110 that is passed 
to a fomnatter 112 which then appropriately displays the 
document. 

[0020] In the case where the requested document 
portion 1 06 is found to be stored in the local cache 1 08, 
a cache memory manager 114 coupled to the formatter 
112 retrieves the requested document 106 directly from 
the local cache memory 108 using appropriate docu- 
ment tags. The formatter 112 then appropriately dis- 
plays the retrieved document 106. It should be noted 
that the cache memory manager 114 provides a gar- 
bage collection sen/ice that purges documents stored 
in the local cache memory 1 08 based upon the available 
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cache memory as well as browser traffic. One cache 
memory management scheme used by the cache mem- 
ory manager 114 preferentially excludes those most re- 
cently requested documents from being garbage col- 
5 lected. In one embodiment, the cache memory manager 
114 varies the number and type of files subject to gar- 
bage collection based in part on the available cache 
memory space. 

[0021 ] Referring now to Fig. 2, a cache memory man- 
to ager 200 in accordance with an embodiment of the in- 
vention, is shown. It should be noted that the cache 
memory manager 200 is one embodiment of the cache 
memory manager 1 1 4 shown in Fig. 1 . The cache mem- 
ory manager 200 includes a document key stack 202. 
IS in one embodiment, the document key stack 202 is im- 
plemented as a self cleaning hash table suitable for use 
in a object oriented program and system, such as found 
in a Java Virtual Machine (JVM) environment. It should 
be noted that by self cleaning it is meant that the docu- 
20 ment keys associated with those documents reclaimed 
during garbage collection are purged (cleaned) from the 
document key stack 202. The cache memory manager 
200 also includes a master document list 204 that is also 
implemented as a self cleaning hash table. In the de- 
25 scribed embodiment, the master document list 204 is 
arranged to store document identifiers, typically in the 
form of a document URL, associated with, for example, 
documents stored in the cache memory 108 represent- 
ed by documents 206 - 21 0. Each of the documents 206 
30 - 21 0 have an associated document identifier in the form 
of universal resource locators, URLq, URL^, URL2, re- 
spectively. 

[0022] In one implementation of the invention, the 
document key stack 202 includes a number of available 

3S document key stack locations, such as 100 - 104, that 
are each used to store a document key corresponding 
to a particular document or documents currently stored 
in the local cache memory 1 08. By way of example, the 
document key stack location 100 contains a document 

40 key keyo that corresponds to the document 206 having 
the universal resource locator URLq, while the location 
102 contains document key key^ corresponding to the 
document 208 having the universal resource locator 
URLv In this way, each document stored in the local 

45 cache memory 108 can be uniquely identified by the 
combination of URL and document key, referred to as a 
document tag. By way of example, the document 206 
lias a corresponding document tag (URL^, keyo), while 
the document 208 has a corresponding document tag 

50 (URL-,, key^). It should be noted, that in the described 
embodiment, the document 210 (having the universal 
resource locator URL2) is also associated with the doc- 
ument key keyo- In this way, the size (i.e., the number 
of locations) of the document key stack 202 can be less 

55 than the total number of documents stored in the local 
cache memory 108. 

[0023] In the described embodiment, the master doc- 
ument list 204 includes a document identifier, typically 
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in the form of the universal resource locator URL, for 
every document stored in the local cache memory 1 08 
or requested by the browser 100. By way of example, 
each of the documents 206 - 210 has its corresponding 
universal resource locator URL stored in one of the 
available locations Included in the master document list 
204. 

[0024] As implemented, any document having its cor- 
responding document key included in the document key 
stack 202 exists in a condition known as strongly refer- 
enced. In the context of an object oriented operating 
system that uses garbage collection to reclaim unused 
memory, such as the Java runtime environment, a ref- 
erence is much like a pointer to an object in other object 
oriented systems, a term well known in the art. A refer- 
ence differs from a pointer in how it interacts with the 
garbage collection system. The garbage collector will 
not collect objects that it considers strongly referenced. 
An object is strongly referenced if a path of references 
can be found form the root set (which a primordial set 
of references that are never collected until the whole 
system is terminated) to the object in question. Docu- 
ments with their document keys in the document key 
stack 202 are considered strongly referenced because 
a path from the root set to the document key stack 202 
always exists, and the document key stack 202 has a 
reference to those documents whose keys it contains, 
thus completing the path from the root set to the docu- 
ment. 

[0025] When an object has no references to it at ail 
from the root set, the object is said to he unreachable, 
and therefore able to be collected as unused memory 
by the garbage collector. 

[0026] Some garbage collected object oriented sys- 
tems, such as the Java runtime environment, also allow 
for what are called weak references. Weak references 
act just like strong references in that they are much like 
pointer to objects in other object oriented computer sys- 
tems. Weak references differ from strong references in 
terms of their interactions with the garbage collector. 
When a path from the root set to an object can be found 
only by crossing any number of weak references, that 
object is said to be weakly referenced. Weakly refer- 
enced objects may be reclaimed by the garbage collec- 
tor at any time. However, weakly referenced objects are 
not unreachable. If the garbage collector has not yet col- 
lected the weakly referenced object, it may still be used 
through the weak reference in all ways that a strongly 
referenced object may be used. At any time, however, 
the weakly referenced object may be collected by the 
garbage collector. Weak references, therefore, are use- 
ful for building caches that are flushed only when mem- 
ory is low of when system performance requires it. 
[0027] Therefore, as long as a cache memory man- 
ager maintains at least a strong reference, the docu- 
ment is not subject to garbage collection. On the other 
hand, if a document has only associated with it a weak 
reference, the document is subject to being reclaimed 



by the garbage collector. 

[0028] A typical situation where a document that is 
currently stored in the local cache memory 108 be- 
comes subject to garbage collection is when a particular 
5 document has not been recently requested as deter- 
mined by the scheduling protocol executed by the cache 
memory manager 200. In this case, the lifetime (i.e., the 
expected period of time between requests) of the doc- 
ument has probably elapsed and maintaining the docu- 

10 ment in the local cache memory 108 is not memory 
space efficient since it he precludes other more recently 
requested documents from being stored locally in the 
local cache memory 108. By abolishing the strong ref- 
erence to the least recently requested document, that 

^5 particular document becomes subject to being re- 
claimed from the local cache memory during a subse- 
quent garbage collection cycle since it now only has a 
weak reference associated with it. In this way, valuable 
cache memory is made available for locally storing more 

20 recently requested documents. On the other hand, if suf- 
ficient memory is available so that garbage collection is 
not deemed necessary, the weakly referenced docu- 
ment will remain in the cache until garbage collection 
does indeed occur. 

25 [0029] By way of example. Fig. 3 illustrates a situation 
where the document 208 has not been recently request- 
ed and as such its document key key^ has been dropped 
from the document key stack 202. Another situation 
where the document key can be dropped from the doc- 

30 ument key stack 202 is when the depth of document key 
stack 202 itself is reduced such that certain of the doc- 
ument keys stored therein are dropped. In either case, 
any document not having its corresponding document 
key included in the document key stack 202 will result 

35 in the corresponding strong reference being abolished 
thereby leaving only a weak reference from the master 
document list 204 to the document 208. In this situation, 
only the document 208 will be reclaimed from the local 
cache memory 108 during a subsequent garbage col- 

40 lection cycle leaving documents 206 and 21 0 stored in 
the local cache memory 108. 

[0030] Therefore, in those situations where local 
cache memory space is limited, it would be desirable to 
have a relatively greater number of documents having 

45 only weak references in comparison to those docu- 
ments having a strong reference. In this way, those doc- 
uments having only a weak reference will be reclaimed 
during garbage collection thereby selectively freeing up 
valuable cache memory space during garbage collec- 

50 tion. 

[0031] However, in those situations where having 
documents readily available for local retrieval, such as 
in browser type applications, where availability of local 
memory space is less of a concern than system perform- 
55 ance, then having a relatively greater number of docu- 
ments having a strong reference in comparison to those 
files having only weak references is desirable. In this 
way, garbage collection will not purge those documents 



5 



EP 1 046 997 A2 



10 



having a strong reference thereby leaving only those 
documents stored in the local cache memory 108. 
[0032] Therefore, in accordance with an embodiment 
of the invention, the cache memory manager 200 pro- 
vides the capability of selectively choosing which docu- 5 
ments and how many documents have strong referenc- 
es in relation to those documents having only a weak 
reference. An example of this capability is shown in Fig. 
4 where a new document key stack 402 has been cre- 
ated by the cache memory manager 200 having only a 
single location 402 for storing document keys. By reduc- 
ing the number of document keys that can be stored in 
the document key stack 400, the number of documents 
having an associated strong reference is commensura- 
bly reduced. In this way, more documents stored in the ?5 
local cache memory 108 are subject to garbage collec- 
tion thereby periodically freeing up valuable cache 
memory space. This arrangement is appropriate for use 
in those applications where local memory is severely 
constrained, as in Internet telephones, and the like. 
[0033] More particularly, in the situation shown in Fig. 
4, the documents 206 and 208 no longer have their re- 
spective document keys stored in the document key 
stack 402 and are thus subject to being reclaimed from 
the local memory 1 08 during a subsequent garbage col- ^5 
lection cycle. It should be noted, however, that a weak 
reference to the master document list 404 still remains 
valid. This retention of the weak reference to the master 
document list 404 facilitates re-inserting the document 
key into the document key stack 202 associated with the 30 
document 206, for example, when the document 206 is 
again (if ever) requested. 

[0034] In this way, the ratio of those documents hav- 
ing an associated strong reference to those having only 
a weak reference can be adjusted by increasing or de- 55 
creasing the depth (i.e., number of available locations) 
of the document key stack. By adjusting this ratio, the 
number (and kind) of documents reclaimed during gar- 
bage collection can adjusted accordingly, based upon 
such factors as available cache memory space, browser 
traffic, etc. 

[0035] For example, if cache memory space is limited, 
then the depth of the document key stack can be re- 
duced such that relatively fewer documents have strong 
references thereby increasing the number of documents ^ 
having only a weak reference and thereby subject to 
garbage collection. Conversely, by increasing the depth 
of the document key stack, relatively more documents 
can be made to have a strong reference and thereby not 
subject to garbage collection resulting in an Increase in 
the number of documents stored locally. It should be not- 
ed, that it is contemplated that by dynamically linking the 
depth of the document key stack to the available mem- 
ory space of the local cache memory 108, a self regu- 
lating cache memory manager 500 can be implemented ^5 
as shown in Fig. 5. The self regulating cache manager 
500 periodically determines the amount of available 
memory space in the local cache memory 108 and 



based upon that determination, varies the depth of a 
document key stuck 502. By way of example, if it is de- 
termined that the available cache memory space in the 
cache memory 108 is less than an predetermined 
threshold, then the number of locations in the document 
key stack 502 is reduced. 1 n this way, the number of files 
reclaimed during a subsequent garbage collection cycle 
is increased so as to increase the available cache mem- 
ory space. In other situations, the self regulating cache 
manager 500 can periodically vary the depth of the doc- 
ument key stack 502 based upon other factors, such as 
overall system performance, etc. Referring now to Fig. 
6, a flowchart detailing a process 600 for retrieving a 
document in accordance with an embodiment of the in- 
vention is shown. The process 600 begins at 602 when 
the cache memory manager receives a document tag 
corresponding to a requested document. In the de- 
scribed embodiment, the document-tag includes the 
document key and an associated universal resource lo- 
cator URL unique to the requested document. The 
cache memory manager then determines if the docu- 
ment key is present in the document key stack at 604. 
If the document key is present, then the document key 
holder associated with the document key is moved to 
the top of the document key stack at 606. In this way, 
the most recently requested documents arc preferen- 
tially stored in the local cache memory over the least 
recently requested documents. Returning to 604, if the 
document key holder is not present in the document key 
stack, then a new document key holder is instantiated 
at 608 and the instantiated document key holder is 
moved to the top of the document key stack at 606. By 
managing the most recently requested document keys, 
the cache memory manager is capable of maintaining 
the most recently requested documents stored within 
the cache memory. In this way, the ratio of hits to misses 
is substantially reduced thereby improving system per- 
formance. 

[0036] In either case, once the document key holder 
has been added to the top of the document key stack, 
the document associated with the document tag com- 
prising the document key holder and the document URL 
is retrieved at 610 and returned at 612. 
[0037] Fig. 7 is a flowchart detailing the process 61 0 
for retrieving a document using the associated docu- 
ment key and document URL in accordance with an em- 
bodiment of the invention. The process 610 begins at 
702 wherein the cache memory manager determines if 
the received document tag that includes the document 
URL is present in the document key stack. When the 
document tag is present in the document key stack, the 
associated document is stored in the cache memory and 
is not reclaimable by the garbage collector since it has 
a strong reference associated with it. When the docu- 
ment tag is present in the document key stack, , the doc- 
ument associated with the document tag that includes 
the received document URL and corresponding docu- 
ment key is returned at 704. Alternatively, if the docu- 
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ment tag is not present in the document key stack, then 
a determination is made at 706 whether or not the re- 
ceived document URL is present in the master docu- 
ment list. In those situations where a document key as- 
sociated with a requested document is not located in the 
document key stack but does have its document URL 
located in the master file stack, the document is stored 
in the cache memory but is subject to being reclaimed 
by the garbage collector. The requested document, 
therefore, must have a strong reference associated with 
it before the next garbage collection cycle. If present in 
the master document list, then the document key is ap- 
propriately inserted into the document key stack at 708. 
If, however, the received document URL is not present 
in the master document list, then a weak reference is 
created to the document in the master document list at 
710- In this way, by inserting the document key into the 
document key stack, a strong reference is established 
for the corresponding document thereby precluding it 
from being reclaimed during garbage collection. In ei- 
ther case, control is passed to 704 where the document 
is returned. 

[0038] As discussed above, the document key stack 
can be adjusted in those situations where system per- 
formance is dynamically dependent upon the available 
cache memory space. Such a process of adjusting the 
depth of a document key stack is illustrated In Fig. 8 de- 
tailing a process 800 In accordance with an embodiment 
of the invention. The process 800 begins at 802 by cre- 
ating an array having the desired key stack depth. The 
key stack depth is typically directly proportional to the 
number of documents stored in the cache memory hav- 
ing associated strong references. In those cases, for ex- 
ample, where cache memory space is limited, the key 
stack depth Is commensurably reduced in order to ac- 
commodate only the most recently retrieved docu- 
ments. On the other hand, when cache memory space 
is not a constraining factor, or where system perform- 
ance is of greater importance, then the key stack depth 
is commensurably Increased. At 804, the most recently 
requested document key holders are copied from the 
old array to the new array. In this way, the scheduling 
protocol heretofore followed is maintained even though 
the number of documents having associated document 
keys in the adjusted key stack has changed based upon 
the change in key stack depth. At 606, the pointer to the 
old array is swapped to the new array thereby replacing 
the old key stack array with the new key stack array hav- 
ing the adjusted key stack depth. 
[0039] Computer system 900 or, more specifically, 
CPUs 902, may be arranged to support a virtual ma- 
chine, as will be appreciated by those skilled in the art. 
As is well known In the art, ROM acts to transfer data 
and Instructions uni-directionally to the CPUs 902, while 
RAM is used typically to transfer data and instructions 
in a bi-directional manner. CPUs 902 may generally in- 
clude any number of processors. Both primary storage 
devices 904, 906 may include any suitable computer- 



46 997A2 12 

readable media. A secondary storage medium 908, 
which Is typically a mass memory device, is also coupled 
bi-directionally to CPUs 902 and provides additional da- 
ta storage capacity. The mass memory device 908 is a 

5 computer-readable medium that may be used to store 
programs including computer code, data, and the like. 
Typically, mass memory device 908 is a storage medium 
such as a hard disk or a tape which generally slower 
than primary storage devices 904, 906. Mass memory 
storage device 908 may take the form of a magnetic or 
paper tape reader or some other well-known device. It 
will be appreciated that the information retained within 
the mass memory device 908, may, in appropriate cas- 
es, be Incorporated in standard fashion as part of RAM 

'5 906 as virtual memory. A specific primary storage device 
904 such as a CD-ROM may also pass data uni-direc- 
tionally to the CPUs 902. 

[0040] CPUs 902 are also coupled to one or more in- 
put/output devices 910 that may Include, but are not lim- 

20 Ited to. devices such as video monitors, track balls, 
mice, keyboards, microphones, touch-sensitive dis- 
plays, transducer card readers, magnetic or paper tape 
readers, tablets, styluses, voice or handwriting recog- 
nizers, or other well-known input devices such as, of 

25 course, other computers. Finally CPUs 902 optionally 
may be coupled to a computer or telecommunications 
network, e.g., an Internet network or an intranet net- 
work, using a network connection as shown generally 
at 912. With such a network connection, it is contem- 

30 plated that the CPUs 902 might receive Information from 
the network, or might output information to the network 
In the course of performing the above-described method 
steps. Such information, which is often represented as 
a sequence of instructions to be executed using CPUs 

35 902, may be received from and outputted to the network, 
for example, in the form of a computer data signal em- 
bodied in a carrier wave. The above-described devices 
and materials will be familiar to those of skill in the com- 
puter hardware and software arts. 

40 [0041] Although only a few embodiments of the 
present invention have been described, It should be un- 
derstood that the present invention may be embodied 
in many other specific forms without departing from the 
spirit or the scope of the present invention. By way of 

45 example, any form of digitized information storable in a 
cache memory can be used, such as images, text files, 
etc. 

[0042] Although the methods of managing a cache 
memory in accordance with the present invention are 

50 particularly suitable for Implementation with respect to 
a Java™ based environment, the methods may gener- 
ally be applied in any suitable object-based environ- 
ment. In particular, the methods are suitable for use in 
platform-independent object-based environments. It 

55 should be appreciated that the methods may also be im- 
plemented in some distributed object-oriented systems. 
[0043] While the present invention has been de- 
scribed as being used with a computer system that has 
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an associated web browser, it should be appreciated 
that the present invention may generally be implement- 
ed on any suitable object-oriented computer system 
having a cache memory. Therefore, the present exam- 
ples are to be considered as illustrative and not restric- 
tive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of 
the appended claims along with their full scope of equiv- 
alents. 



Claims 

1. A computer implemented cache memory manager 
for managing memory space in a cache memory, 
comprising: 

a document key stack having a depth of stack 
locations each being arranged to store a docu- 
ment key associated with a document stored in 
the cache memory, wherein the presence of the 
document key in the document key stack indi- 
cates that the associated document has a 
strong reference associated therewith; 
a master document file having a plurality of file 
locations each being arranged to store a docu- 
ment identifier used to uniquely identify an as- 
sociated document stored in the cache memo- 
ry, wherein the presence of the document iden- 
tifier in the master document file indicates that 
the associated document has only a weak ref- 
erence associated therewith; and 
a garbage collector arranged to reclaim those 
documents stored in the cache memory that are 
only weakly referenced and not those docu- 
ments that are strongly referenced such that 
cache memory space commensurate with the 
reclaimed documents is periodically made 
available to store more recently requested doc- 
uments. 

2. A cache memory manager as recited in claim 1, 
wherein the depth of the document key stack is var- 
ied in direct proportion to the n umber of strongly ref- 
erenced documents stored in the cache memory. 



ument to be retained in the cache memory. 

5. A cache memory manager as recited in claim 3, 
wherein if the document key is not present in the 
5 document key stack, then a determination is made 
if the document identifier associated with the most 
recently requested document is present in the mas- 
ter document file. 

10 6. A cache memory manager as recited in claim 5, 
wherein if the document identifier is present in the 
master document file, a document key associated 
with the most recently requested document is in- 
stantiated and inserted into a first document key 

15 stack location such that the most recently requested 
document is the most likely document to be retained 
in the cache memory. 

7. A cache memory manager as recited in claim 5, 
20 wherein if the document identifier associated with 

the most recently requested document is not 
present in the master document files the document 
identifier is inserted into the master document file 
and a document key associated with the most re- 
25 cently requested document is instantiated and in- 
serted into a first document key stack location such 
that the most recently requested document is the 
most likely document to be retained in the cache 
memory. 

30 

8. A cache memory manager as recited in claim 2, 
wherein when the depth of the document key stack 
is reduced, the quantity of documents stored in the 
cache memory reclaimed by the garbage collector 

35 Is increased, thereby making available cache mem- 
ory space suitable for retaining more recently re- 
quested documents. 

9. A cache memory manager as recited in claim 2, 
40 wherein when the depth of the document key stack 

is increased, the quantity of documents stored in the 
cache memory reclaimed by the garbage collector 
is decreased, thereby increasing the quantity of 
documents available for retrieval from the cache 
45 memory. 



3. A cache memory manager as recited in claim 2, 
wherein when a document having a document iden- 
tifier is most recently requested, a determination is 
made if a document key associated with the most so 
recently requested document is present in the doc- 
ument key stack. 

4. A cache memory manager as recited in claim 3, 
wherein if the document key is present in the doc- 55 
ument key stack, the document key is moved to a 
first document key stack location such that the most 
recently requested document is the most likely doc- 



10. A cache memory manager as recited in claim 1, 
wherein the cache memory is coupled to a web 
browser. 

11. A cache memory manager as recited in claim 10, 
wherein the document is a Hyper Text Markup Text 
(HTML) document. 

12. A cache memory manager as recited in claim 11, 
wherein the document identifier is a universal re- 
source locator (URL) that uniquely identifies the re- 
quested document in the context of the Internet. 
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13. A cache memory manager as recited in claim 1, 
wherein the dcxument key stack and the master 
document file take the form of a self cleaning hash 
table. 
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